The use of embedded processors is becoming a common practice in a wide range of systems. A complex server may include upwards of 70 or more processors performing different functions. For example, some processors may perform functions related to system manageability and some may be system processors running user applications. Among these processors, there may be numerous types of processors (ARM, PA-RISC, 8086, IA-32, IA64). Each type of processor will require its own firmware, because each type is essentially a different architecture. Also, some processors of the same type may be performing different functions. For example, one 8086 embedded processor monitors fans while another monitors power. These two processors would be running different firmware because they have different tasks.
The firmware that runs on each of the processors sometimes needs to be updated, for example, to incorporate enhancements or fix bugs. For processors that have access to a remote computer, such as a server accessed through a network connection, updates are typically downloaded to the processors. Updates may be downloaded to a targeted processor in a multi-processor system needing the firmware update.
When multiple processors in a system are running different versions of firmware, compatibility issues between the different versions may arise. For example, firmware running on one processor may be dependent on functions performed by firmware running on another processor in the system. Therefore, the versions of firmware running on each of the processors must be monitored to insure that the versions are compatible and that debugged versions of the firmware are currently running.
When dependencies exist between firmware running on different processors, a “recipe” (e.g., a set of versions of firmware that are compatible with each other) is required to determine what version each processor should be running for the system to function properly. For systems having a large number of processors, the process of checking the versions of firmware running on the processors against the “recipe” is tedious and is prone to error.
Conventionally, the process of checking the versions of firmware running on the processors against the “recipe” is performed manually, for example, by a system administrator running version checking and update utilities. This technique requires the administrator to know how to access the image server (i.e., the server containing the updates downloaded to the processors), what are the current versions of the firmware running on the processors, and what versions should be currently running (e.g., based on a current “recipe”). It is often very difficult for the administrator to keep up with what the latest recipe is and mistakes are often made for updates provoked by the system administrator. The likelihood of error increases for large and complex systems. Also, when a recipe is changing on a daily/weekly basis, such as during product development, the time required to maintain the system and perform software updates may be excessive.